Giải mã CORS: Tìm hiểu sâu về xử lý yêu cầu Preflight trong JavaScript

Trong thế giới phát triển web không ngừng mở rộng, bảo mật là yếu tố tối quan trọng. Chia sẻ tài nguyên chéo nguồn gốc (CORS) là một cơ chế bảo mật quan trọng được các trình duyệt web triển khai để hạn chế các trang web thực hiện yêu cầu đến một tên miền khác với tên miền đã cung cấp trang web đó. Đây là một tính năng bảo mật cơ bản được thiết kế để ngăn chặn các trang web độc hại truy cập dữ liệu nhạy cảm. Hướng dẫn toàn diện này sẽ đi sâu vào sự phức tạp của CORS, tập trung đặc biệt vào việc xử lý yêu cầu preflight. Chúng ta sẽ khám phá 'tại sao,' 'cái gì,' và 'làm thế nào' về CORS, cung cấp các ví dụ thực tế và giải pháp cho các vấn đề thường gặp mà các nhà phát triển trên toàn thế giới phải đối mặt.

Tìm hiểu về Chính sách Cùng Nguồn gốc

Cốt lõi của CORS là Chính sách Cùng Nguồn gốc (SOP). Chính sách này là một cơ chế bảo mật ở cấp độ trình duyệt, hạn chế các script chạy trên một nguồn gốc truy cập tài nguyên từ một nguồn gốc khác. Một nguồn gốc được định nghĩa bởi giao thức (ví dụ: HTTP hoặc HTTPS), tên miền (ví dụ: example.com), và cổng (ví dụ: 80 hoặc 443). Hai URL có cùng nguồn gốc nếu ba thành phần này khớp chính xác.

Ví dụ:

• https://www.example.com/app1/index.html và https://www.example.com/app2/index.html có cùng nguồn gốc (cùng giao thức, tên miền và cổng).
• https://www.example.com/index.html và http://www.example.com/index.html có nguồn gốc khác nhau (khác giao thức).
• https://www.example.com/index.html và https://api.example.com/index.html có nguồn gốc khác nhau (tên miền phụ khác nhau được coi là tên miền khác nhau).
• https://www.example.com:8080/index.html và https://www.example.com/index.html có nguồn gốc khác nhau (khác cổng).

SOP được thiết kế để ngăn chặn các script độc hại trên một trang web truy cập dữ liệu nhạy cảm, chẳng hạn như cookie hoặc thông tin xác thực người dùng, trên một trang web khác. Mặc dù cần thiết cho bảo mật, SOP cũng có thể gây hạn chế, đặc biệt khi cần các yêu cầu chéo nguồn gốc hợp pháp.

Chia sẻ tài nguyên chéo nguồn gốc (CORS) là gì?

CORS là một cơ chế cho phép máy chủ chỉ định những nguồn gốc nào (tên miền, lược đồ hoặc cổng) được phép truy cập tài nguyên của chúng. Về cơ bản, nó nới lỏng SOP, cho phép truy cập chéo nguồn gốc có kiểm soát. CORS được triển khai bằng cách sử dụng các header HTTP được trao đổi giữa máy khách (thường là trình duyệt web) và máy chủ.

Khi trình duyệt thực hiện một yêu cầu chéo nguồn gốc (tức là một yêu cầu đến một nguồn gốc khác với trang hiện tại), trước tiên nó sẽ kiểm tra xem máy chủ có cho phép yêu cầu đó hay không. Điều này được thực hiện bằng cách kiểm tra header Access-Control-Allow-Origin trong phản hồi của máy chủ. Nếu nguồn gốc của yêu cầu được liệt kê trong header này (hoặc nếu header được đặt thành *, cho phép tất cả các nguồn gốc), trình duyệt sẽ cho phép yêu cầu tiếp tục. Ngược lại, trình duyệt sẽ chặn yêu cầu, ngăn không cho mã JavaScript truy cập dữ liệu phản hồi.

Vai trò của Yêu cầu Preflight

Đối với một số loại yêu cầu chéo nguồn gốc nhất định, trình duyệt sẽ khởi tạo một yêu cầu preflight. Đây là một yêu cầu OPTIONS được gửi đến máy chủ trước yêu cầu thực tế. Mục đích của yêu cầu preflight là để xác định xem máy chủ có sẵn lòng chấp nhận yêu cầu thực tế hay không. Máy chủ trả lời yêu cầu preflight với thông tin về các phương thức, header được phép và các hạn chế khác.

Yêu cầu preflight được kích hoạt khi yêu cầu chéo nguồn gốc đáp ứng bất kỳ điều kiện nào sau đây:

• Phương thức yêu cầu không phải là GET, HEAD, hoặc POST.
• Yêu cầu bao gồm các header tùy chỉnh (tức là các header khác với những header được trình duyệt tự động thêm vào).
• Header Content-Type được đặt thành bất kỳ giá trị nào khác ngoài application/x-www-form-urlencoded, multipart/form-data, hoặc text/plain.
• Yêu cầu sử dụng các đối tượng ReadableStream trong phần thân.

Ví dụ, một yêu cầu PUT với Content-Type là application/json sẽ kích hoạt một yêu cầu preflight vì nó sử dụng một phương thức khác với các phương thức được phép và một kiểu nội dung có thể không được phép.

Tại sao cần Yêu cầu Preflight?

Yêu cầu preflight rất cần thiết cho bảo mật vì chúng cung cấp cho máy chủ cơ hội để từ chối các yêu cầu chéo nguồn gốc có khả năng gây hại trước khi chúng được thực thi. Nếu không có yêu cầu preflight, một trang web độc hại có thể gửi các yêu cầu tùy ý đến máy chủ mà không có sự đồng ý rõ ràng của máy chủ. Yêu cầu preflight cho phép máy chủ xác thực rằng yêu cầu đó có thể chấp nhận được và ngăn chặn các hoạt động có khả năng gây hại.

Xử lý Yêu cầu Preflight phía Máy chủ

Xử lý đúng cách các yêu cầu preflight là rất quan trọng để đảm bảo ứng dụng web của bạn hoạt động chính xác và an toàn. Máy chủ phải trả lời yêu cầu OPTIONS với các header CORS thích hợp để cho biết yêu cầu thực tế có được phép hay không.

Dưới đây là phân tích các header CORS chính được sử dụng trong các phản hồi preflight:

• Access-Control-Allow-Origin: Header này chỉ định (các) nguồn gốc được phép truy cập tài nguyên. Nó có thể được đặt thành một nguồn gốc cụ thể (ví dụ: https://www.example.com) hoặc * để cho phép tất cả các nguồn gốc. Tuy nhiên, việc sử dụng * thường không được khuyến khích vì lý do bảo mật, đặc biệt nếu máy chủ xử lý dữ liệu nhạy cảm.
• Access-Control-Allow-Methods: Header này chỉ định các phương thức HTTP được phép cho yêu cầu chéo nguồn gốc (ví dụ: GET, POST, PUT, DELETE).
• Access-Control-Allow-Headers: Header này chỉ định danh sách các header HTTP không chuẩn được phép trong yêu cầu thực tế. Điều này là cần thiết nếu máy khách đang gửi các header tùy chỉnh, chẳng hạn như X-Custom-Header hoặc Authorization.
• Access-Control-Allow-Credentials: Header này cho biết yêu cầu thực tế có thể bao gồm thông tin xác thực, chẳng hạn như cookie hoặc header ủy quyền hay không. Nó phải được đặt thành true nếu mã phía máy khách đang gửi thông tin xác thực và máy chủ nên chấp nhận chúng. Lưu ý: khi header này được đặt thành `true`, `Access-Control-Allow-Origin` *không thể* được đặt thành `*`. Bạn phải chỉ định nguồn gốc.
• Access-Control-Max-Age: Header này chỉ định khoảng thời gian tối đa (tính bằng giây) mà trình duyệt có thể lưu vào bộ đệm phản hồi preflight. Điều này có thể giúp cải thiện hiệu suất bằng cách giảm số lượng yêu cầu preflight được gửi đi.

Ví dụ: Xử lý Yêu cầu Preflight trong Node.js với Express

Đây là một ví dụ về cách xử lý yêu cầu preflight trong một ứng dụng Node.js sử dụng framework Express:

const express = require('express');
const cors = require('cors');
const app = express();

// Bật CORS cho tất cả các nguồn gốc (chỉ cho mục đích phát triển!)
// Trong môi trường production, hãy chỉ định các nguồn gốc được phép để bảo mật tốt hơn.
app.use(cors()); //hoặc app.use(cors({origin: 'https://www.example.com'}));

// Route để xử lý các yêu cầu OPTIONS (preflight)
app.options('/data', cors()); // Bật CORS cho một route duy nhất. Hoặc chỉ định nguồn gốc: cors({origin: 'https://www.example.com'})

// Route để xử lý các yêu cầu GET
app.get('/data', (req, res) => {
  res.json({ message: 'Đây là dữ liệu chéo nguồn gốc!' });
});


// Route để xử lý preflight và yêu cầu post
app.options('/resource', cors()); // bật yêu cầu pre-flight cho yêu cầu DELETE
app.delete('/resource', cors(), (req, res, next) => {
  res.send('xóa tài nguyên')
})


const port = 3000;
app.listen(port, () => {
  console.log(`Máy chủ đang lắng nghe trên cổng ${port}`);
});

Trong ví dụ này, chúng tôi sử dụng middleware cors để xử lý các yêu cầu CORS. Để kiểm soát chi tiết hơn, CORS có thể được bật trên cơ sở từng route. Lưu ý: trong môi trường production, rất nên chỉ định các nguồn gốc được phép bằng cách sử dụng tùy chọn origin thay vì cho phép tất cả các nguồn gốc. Việc cho phép tất cả các nguồn gốc bằng cách sử dụng * có thể khiến ứng dụng của bạn gặp phải các lỗ hổng bảo mật.

Ví dụ: Xử lý Yêu cầu Preflight trong Python với Flask

Đây là một ví dụ về cách xử lý yêu cầu preflight trong một ứng dụng Python sử dụng framework Flask và tiện ích mở rộng flask_cors:

from flask import Flask, jsonify
from flask_cors import CORS, cross_origin

app = Flask(__name__)
CORS(app)  # Bật CORS cho tất cả các route

@app.route('/data')
@cross_origin()
def get_data():
    data = {"message": "Đây là dữ liệu chéo nguồn gốc!"}
    return jsonify(data)

if __name__ == '__main__':
    app.run(debug=True)

Đây là cách sử dụng đơn giản nhất. Giống như trước đây, các nguồn gốc có thể bị hạn chế. Xem tài liệu của flask-cors để biết chi tiết.

Ví dụ: Xử lý Yêu cầu Preflight trong Java với Spring Boot

Đây là một ví dụ về cách xử lý yêu cầu preflight trong một ứng dụng Java sử dụng Spring Boot:

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.context.annotation.Bean;
import org.springframework.web.servlet.config.annotation.CorsRegistry;
import org.springframework.web.servlet.config.annotation.WebMvcConfigurer;

@SpringBootApplication
public class CorsApplication {

    public static void main(String[] args) {
        SpringApplication.run(CorsApplication.class, args);
    }

    @Bean
    public WebMvcConfigurer corsConfigurer() {
        return new WebMvcConfigurer() {
            @Override
            public void addCorsMappings(CorsRegistry registry) {
                registry.addMapping("/data").allowedOrigins("http://localhost:8080");
            }
        };
    }
}

Và controller tương ứng:

import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class DataController {

    @GetMapping("/data")
    public String getData() {
        return "Đây là dữ liệu chéo nguồn gốc!";
    }
}

Các vấn đề CORS thường gặp và giải pháp

Mặc dù quan trọng, CORS thường có thể là nguồn gây khó chịu cho các nhà phát triển. Dưới đây là một số vấn đề CORS thường gặp và giải pháp của chúng:

1. Lỗi: "No 'Access-Control-Allow-Origin' header is present on the requested resource." (Không có header 'Access-Control-Allow-Origin' trên tài nguyên được yêu cầu.)

   Lỗi này cho biết máy chủ không trả về header Access-Control-Allow-Origin trong phản hồi của nó. Để khắc phục, hãy đảm bảo rằng máy chủ được cấu hình để bao gồm header này và nó được đặt thành nguồn gốc chính xác hoặc * (nếu phù hợp).

   Giải pháp: Cấu hình máy chủ để bao gồm header `Access-Control-Allow-Origin` trong phản hồi của nó, đặt nó thành nguồn gốc của trang web yêu cầu hoặc `*` để cho phép tất cả các nguồn gốc (sử dụng cẩn thận).

2. Lỗi: "Response to preflight request doesn't pass access control check: Request header field X-Custom-Header is not allowed by Access-Control-Allow-Headers in preflight response." (Phản hồi cho yêu cầu preflight không vượt qua kiểm tra kiểm soát truy cập: Trường header yêu cầu X-Custom-Header không được phép bởi Access-Control-Allow-Headers trong phản hồi preflight.)

   Lỗi này cho biết máy chủ không cho phép header tùy chỉnh (X-Custom-Header trong ví dụ này) trong yêu cầu chéo nguồn gốc. Để khắc phục, hãy đảm bảo rằng máy chủ bao gồm header này trong header Access-Control-Allow-Headers trong phản hồi preflight.

   Giải pháp: Thêm header tùy chỉnh (ví dụ: `X-Custom-Header`) vào header `Access-Control-Allow-Headers` trong phản hồi preflight của máy chủ.

3. Lỗi: "Credentials flag is 'true', but the 'Access-Control-Allow-Origin' header is '*'." (Cờ credentials là 'true', nhưng header 'Access-Control-Allow-Origin' là '*'.)

   Khi header Access-Control-Allow-Credentials được đặt thành true, header Access-Control-Allow-Origin phải được đặt thành một nguồn gốc cụ thể, không phải *. Điều này là do việc cho phép thông tin xác thực từ tất cả các nguồn gốc sẽ là một rủi ro bảo mật.

   Giải pháp: Khi sử dụng thông tin xác thực, hãy đặt `Access-Control-Allow-Origin` thành một nguồn gốc cụ thể thay vì `*`.

4. Yêu cầu preflight không được gửi đi.

   Kiểm tra kỹ xem mã Javascript của bạn có bao gồm thuộc tính `credentials: 'include'` hay không. Đồng thời kiểm tra xem máy chủ của bạn có cho phép `Access-Control-Allow-Credentials: true` hay không.

5. Cấu hình xung đột giữa máy chủ và máy khách.

   Kiểm tra cẩn thận cấu hình CORS phía máy chủ cùng với các cài đặt phía máy khách. Sự không khớp (ví dụ: máy chủ chỉ cho phép yêu cầu GET nhưng máy khách gửi POST) sẽ gây ra lỗi CORS.

CORS và các Thực tiễn Bảo mật Tốt nhất

Mặc dù CORS cho phép truy cập chéo nguồn gốc có kiểm soát, điều cần thiết là phải tuân theo các thực tiễn bảo mật tốt nhất để ngăn chặn các lỗ hổng:

• Tránh sử dụng * trong header Access-Control-Allow-Origin trong môi trường production. Điều này cho phép tất cả các nguồn gốc truy cập tài nguyên của bạn, có thể là một rủi ro bảo mật. Thay vào đó, hãy chỉ định chính xác các nguồn gốc được phép.
• Cân nhắc cẩn thận các phương thức và header nào được phép. Chỉ cho phép các phương thức và header thực sự cần thiết để ứng dụng của bạn hoạt động chính xác.
• Triển khai các cơ chế xác thực và ủy quyền phù hợp. CORS không phải là sự thay thế cho xác thực và ủy quyền. Đảm bảo rằng API của bạn được bảo vệ bằng các biện pháp bảo mật thích hợp.
• Xác thực và làm sạch tất cả đầu vào của người dùng. Điều này giúp ngăn chặn các cuộc tấn công kịch bản chéo trang (XSS) và các lỗ hổng khác.
• Luôn cập nhật cấu hình CORS phía máy chủ của bạn. Thường xuyên xem xét và cập nhật cấu hình CORS của bạn để đảm bảo rằng nó phù hợp với các yêu cầu bảo mật của ứng dụng.

CORS trong các Môi trường Phát triển Khác nhau

Các vấn đề CORS có thể biểu hiện khác nhau trên các môi trường và công nghệ phát triển khác nhau. Dưới đây là cách tiếp cận CORS trong một vài kịch bản phổ biến:

Môi trường Phát triển Cục bộ

Trong quá trình phát triển cục bộ, các vấn đề CORS có thể đặc biệt khó chịu. Trình duyệt thường chặn các yêu cầu từ máy chủ phát triển cục bộ của bạn (ví dụ: localhost:3000) đến một API từ xa. Một số kỹ thuật có thể giảm bớt sự phiền toái này:

• Tiện ích mở rộng Trình duyệt: Các tiện ích mở rộng như "Allow CORS: Access-Control-Allow-Origin" có thể tạm thời vô hiệu hóa các hạn chế CORS cho mục đích thử nghiệm. Tuy nhiên, *không bao giờ* sử dụng chúng trong môi trường production.
• Máy chủ Proxy: Cấu hình một máy chủ proxy chuyển tiếp các yêu cầu từ máy chủ phát triển cục bộ của bạn đến API từ xa. Điều này thực sự làm cho các yêu cầu trở thành "cùng nguồn gốc" từ góc độ của trình duyệt. Các công cụ như http-proxy-middleware (cho Node.js) rất hữu ích cho việc này.
• Cấu hình CORS trên Máy chủ: Ngay cả trong quá trình phát triển, việc cấu hình máy chủ API của bạn để cho phép rõ ràng các yêu cầu từ nguồn gốc phát triển cục bộ của bạn (ví dụ: http://localhost:3000) là một thực tiễn tốt. Điều này mô phỏng một cấu hình CORS trong thế giới thực và giúp bạn phát hiện các vấn đề sớm.

Môi trường Không máy chủ (ví dụ: AWS Lambda, Google Cloud Functions)

Các hàm không máy chủ thường yêu cầu cấu hình CORS cẩn thận. Nhiều nền tảng không máy chủ cung cấp hỗ trợ CORS tích hợp, nhưng điều quan trọng là phải cấu hình nó một cách chính xác:

• Cài đặt Cụ thể của Nền tảng: Sử dụng các tùy chọn cấu hình CORS tích hợp của nền tảng. Ví dụ, AWS Lambda cho phép bạn chỉ định các nguồn gốc, phương thức và header được phép trực tiếp trong cài đặt API Gateway.
• Middleware/Thư viện: Để linh hoạt hơn, bạn có thể sử dụng middleware hoặc thư viện để xử lý CORS trong mã hàm không máy chủ của mình. Điều này tương tự như các phương pháp được sử dụng trong môi trường máy chủ truyền thống (ví dụ: sử dụng gói `cors` trong các hàm Lambda Node.js).
• Xem xét Phương thức `OPTIONS`: Đảm bảo rằng hàm không máy chủ của bạn xử lý các yêu cầu OPTIONS một cách chính xác. Điều này thường liên quan đến việc tạo một route riêng biệt trả về các header CORS thích hợp.

Phát triển Ứng dụng Di động (ví dụ: React Native, Flutter)

CORS ít được quan tâm trực tiếp hơn đối với các ứng dụng di động gốc (Android, iOS), vì chúng thường không thực thi chính sách cùng nguồn gốc giống như các trình duyệt web. Tuy nhiên, CORS vẫn có thể liên quan nếu ứng dụng di động của bạn sử dụng web view để hiển thị nội dung web hoặc nếu bạn đang sử dụng các framework như React Native hoặc Flutter tận dụng JavaScript:

• Web Views: Nếu ứng dụng di động của bạn sử dụng web view để hiển thị nội dung web, các quy tắc CORS tương tự như trong trình duyệt web sẽ được áp dụng. Cấu hình máy chủ của bạn để cho phép các yêu cầu từ nguồn gốc của nội dung web.
• React Native/Flutter: Các framework này sử dụng JavaScript để thực hiện các yêu cầu API. Mặc dù môi trường gốc có thể không thực thi CORS trực tiếp, các máy khách HTTP cơ bản (ví dụ: fetch) vẫn có thể thể hiện hành vi giống CORS trong một số tình huống nhất định.
• Máy khách HTTP Gốc: Khi thực hiện các yêu cầu API trực tiếp từ mã gốc (ví dụ: sử dụng OkHttp trên Android hoặc URLSession trên iOS), CORS thường không phải là một yếu tố. Tuy nhiên, bạn vẫn cần xem xét các thực tiễn bảo mật tốt nhất như xác thực và ủy quyền phù hợp.

Các Lưu ý Toàn cầu về Cấu hình CORS

Khi cấu hình CORS cho một ứng dụng có thể truy cập toàn cầu, điều quan trọng là phải xem xét các yếu tố như:

• Chủ quyền Dữ liệu: Các quy định ở một số khu vực yêu cầu dữ liệu phải nằm trong khu vực đó. CORS có thể liên quan khi truy cập tài nguyên xuyên biên giới, có khả năng vi phạm luật về nơi cư trú của dữ liệu.
• Chính sách Bảo mật Khu vực: Các quốc gia khác nhau có thể có các quy định và hướng dẫn về an ninh mạng khác nhau ảnh hưởng đến cách CORS nên được triển khai và bảo mật.
• Mạng Phân phối Nội dung (CDN): Đảm bảo rằng CDN của bạn được cấu hình đúng cách để chuyển qua các header CORS cần thiết. Các CDN được cấu hình không đúng cách có thể loại bỏ các header CORS, dẫn đến các lỗi không mong muốn.
• Bộ cân bằng tải và Proxy: Xác minh rằng bất kỳ bộ cân bằng tải hoặc proxy ngược nào trong cơ sở hạ tầng của bạn đang xử lý chính xác các yêu cầu preflight và chuyển qua các header CORS.
• Hỗ trợ Đa ngôn ngữ: Xem xét cách CORS tương tác với các chiến lược quốc tế hóa (i18n) và địa phương hóa (l10n) của ứng dụng. Đảm bảo rằng các chính sách CORS nhất quán trên các phiên bản ngôn ngữ khác nhau của ứng dụng.

Kiểm tra và Gỡ lỗi CORS

Kiểm tra và gỡ lỗi CORS hiệu quả là rất quan trọng. Dưới đây là một số kỹ thuật:

• Công cụ dành cho nhà phát triển của trình duyệt: Bảng điều khiển dành cho nhà phát triển của trình duyệt là điểm dừng chân đầu tiên của bạn. Tab "Network" sẽ hiển thị các yêu cầu preflight và các phản hồi, cho thấy liệu các header CORS có hiện diện và được cấu hình đúng hay không.
• Công cụ dòng lệnh `curl`: Sử dụng `curl -v -X OPTIONS ` để gửi thủ công các yêu cầu preflight và kiểm tra các header phản hồi của máy chủ.
• Các công cụ kiểm tra CORS trực tuyến: Nhiều công cụ trực tuyến có thể giúp xác thực cấu hình CORS của bạn. Chỉ cần tìm kiếm "CORS checker."
• Kiểm thử Đơn vị và Tích hợp: Viết các bài kiểm thử tự động để xác minh rằng cấu hình CORS của bạn đang hoạt động như mong đợi. Các bài kiểm thử này nên bao gồm cả các yêu cầu chéo nguồn gốc thành công và các kịch bản mà CORS nên chặn truy cập.
• Ghi nhật ký và Giám sát: Triển khai ghi nhật ký để theo dõi các sự kiện liên quan đến CORS, chẳng hạn như các yêu cầu preflight và các yêu cầu bị chặn. Giám sát nhật ký của bạn để phát hiện hoạt động đáng ngờ hoặc lỗi cấu hình.

Kết luận

Chia sẻ tài nguyên chéo nguồn gốc (CORS) là một cơ chế bảo mật quan trọng cho phép truy cập chéo nguồn gốc có kiểm soát vào các tài nguyên web. Hiểu cách CORS hoạt động, đặc biệt là các yêu cầu preflight, là rất quan trọng để xây dựng các ứng dụng web an toàn và đáng tin cậy. Bằng cách tuân theo các thực tiễn tốt nhất được nêu trong hướng dẫn này, bạn có thể xử lý hiệu quả các vấn đề CORS và bảo vệ ứng dụng của mình khỏi các lỗ hổng tiềm ẩn. Hãy nhớ luôn ưu tiên bảo mật và cân nhắc cẩn thận các tác động của cấu hình CORS của bạn.

Khi phát triển web phát triển, CORS sẽ tiếp tục là một khía cạnh quan trọng của bảo mật web. Việc cập nhật thông tin về các thực tiễn và kỹ thuật CORS mới nhất là điều cần thiết để xây dựng các ứng dụng web an toàn và có thể truy cập trên toàn cầu.